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ABSTRACT 

A design  language  for  asynchronous  digital  systems  is 
presented.  The  language  translates  onto  a set  of  asynchronous 
logic  modules,  to  form  the  control  structure  of  a digital 
system.  The  behavior  of  these  modules  is  discusseu.  The  process 
of  translating  the  design  language  into  networks  of  these 
modules  is  outlined.  An  example  design  is  presented.  The  design 
language  is  shown  to  be  able  to  describe  machines  having  all  the 
capabilities  normally  required  of  a microcontroller,  as  well  as 
the  capability  to  describe  the  control  of  parallel  processes 
without  unnecessarily  binding  processes  to  one  another.  Parallel 
processes  imply  the  possibility  of  designing  a system  having  the 
potential  for  deadlock.  It  is  shown,  in  a quantitative  way,  that 
it  is  easier  to  check  a design  described  by  the  design  language 
for  correct  syntax  and  absence  of  deadlock,  than  to  check  an 
arbitary  network  of  modules  for  absence  of  deadlock.  It  is 
inferred  from  this,  that  fault-free  design  is  easier  using  the 
design  language. 


-ii- 


TABLE  OK  CONTENTS 


SECTION 


Page 


1 .  INTRODUCTION 


2.  A DESIGN  LANGUAGE 

2.1  The  Two  Statement  Types 

2.2  The  Three  Block  Types.. 

2.3  Comments  On  The  Syntax. 


J 

5 

13 

15 


3.  THE  MODULES 17 

3.1  The  Source  Module 17 

3.2  The  Sink  Module 20 

3-3  The  Wye  Module 20 

3.^  The  Sequence  Module 20 

3.5  The  Junction  Module 22 

3.6  The  Shared  Resource  Module 22 

3.7  The  Decode  Module 22 

3.8  The  Iterate  Module 24 

3-9  Comments  On  The  Modules 24 


4.  THE  TRANSLATION  PROCEDURE 27 

4.1  The  Int:‘.-’:u.->.rr  Connections 27 

4.2  Inter-Block  Connections 31 

4.3  Comments  On  The  Translation  Procedure 32 


5.  AN  EXAMPLE  USING  THE  DL 33 

6.  THE  SCOPE  OF  THE  DL 40 


7.  A QUANTITATIVE  LOOK  AT  THE  DL 42 

7.1  The  Complexity  Of  Checking  The  Syntax  Of  A Design 

In  The  DL 42 

7.2  The  Complexity  Of  Checking  DL  Designs  For  Absence 

Of  Deadlock 45 

7.3  The  Complexity  Of  Checking  An  Arbitrary  Network 

Of  Modules  For  Absence  Of  Deadlock 49 

7.4  Comparing  Computational  Complexities 50 

7.5  Comments  On  The  Quantitative  Look  At  The  DL 52 

8.  CONCLUSION 53 

9.  APPENDIX 54 

10.  REFERENCES 59 


-iii- 


i.intmoduction 


In  an  attempt  to  formalize  the  design  process  for  large 
digital  systems,  many  researchers  have  suggested  the  use  of 
design  languages.  [Bar,  Chu,  Com,  Dul , Fri,  Gla,  Met],  however, 
using  a design  language  ( DL)  does  not  necessarily  facilitate  the 
design  process.  An  ill  conceived  language  can  encumber  the 
design  process  and  fail  to  guide  it  away  from  design  faults. 

The  purpose  of  this  report  is  twofold:  first,  to  develop  a 
DL  for  large  asynchronous  digital  systems  - this  allows  large 
systems  to  be  designed  which  utilize  their  hardware  more 
efficiently  than  the  conventional  synchronous  systems;  second, 
to  specify  the  DL  so  that  design  faults  can  be  easily  avoided  - 
this  is  especially  important  when  designing  asynchronous  as 
opposed  to  synchronous  machines,  because  of  the  greater  number 
of  pitfalls  associated  with  the  asynchronous  design  process. 

The  DL  is  capable  of  being  used  to  design  asynchronous 
digital  systems  which  conform  to  the  following  model:  the  system 
partitions  into  a control  structure  (CS)  and  a data  structure 
(DS).  Actions  in  the  DS  are  assumed  to  be  representable  as 
register  transfers.  The  coordination  of  these  actions  is 
accomplished  by  the  CS.  The  register  transfers  themselves  are 
initiated  by  request  (R)  signals,  which  issue  from  the  CS  and 
travel  over  bidirectional  signal  paths  called  links  to  the  DS. 
Upon  their  completion  acknowledge  (A)  signals  are  transmitted 
back  along  the  links  to  the  CS.  (See  figure  1.1.) 

The  DL  translates  onto  a set  of  eight  asynchronous  modules 
to  produce  a network  of  modules  which  forms  the  CS  of  the  target 
system.  Inter-module  communication  also  occurs  over  links. 

By  constructing  the  CSs  out  of  a small  set  of  modules  that 
communicate  over  links  many  design  pitfalls  are  avoided.  Since 
the  modules  are  simple  and  their  design  is  a one-time  affair, 
classical  asychronous  design  methods  may  be  used  in  their  design 
[Ung].  Once  they  have  been  designed  large  systems  can  be 
constructed  from  them,  without  concern  for  races,  hazards, 
fan-out  constraints,  etc.,  by  virtue  of  the  . rigid  inter-module 
communication  protocol.  Furthermore,  since  networks  of  these 
modules  are  speed-independent  [1]  and  delay-insensitive  [2], 
variations  in  the  response  time  of  the  modules  and  in  the  delays 


1.  A network  of  modules  is  speed-independent  if  its  external 
behavior  is  independent  of  the  delay  of  the  constituent  modules. 

2.  A network  of  modules  is  delay-insensitive  if  its  external 


between  modules  can  be  ignored  . (They  need  only  be  finite,  but 
can  be  unbounded. ) Hence  the  change  in  the  response  time  of 
particular  modules  due  to  aging,  and  the  delays  between  modules 
due  to  their  spatial  distribution,  need  not  be  considered, 
finally  the  common  critism  of  modular  CSs  , that  they  imply  a 
hardwired  CS,  does  not  apply.  There  exists  procedures  for 
translating  networks  of  modules  of  the  type  used  in  this  report 
into  programmable  diode  arrays  without  losing  any  of  the 
desirable  features  outlined  above.  [Pat  75,  Jum] 

Although  modularization  reduces  some  of  the  design  problems 
there  are  still  several  associated  with  the  interconnection 
patterns  of  the  modules  in  CS  networks.  Certain  interconnection 
patterns  result  in  networks  which  eventually  deadlock  or  hang-up 
[1].  (This  phenomenon  is  analagous  to  deadlock  in  operating 
systems.  [Hab])  Recognition  of  this  type  of  design  problem  is  a 
complex  procedure.  The  DL  is  specified  so  that  within  the  class 
of  networks  that  it  describes  recognizing  potential  deadlock  is 
very  much  simplified.  This  advantage  would  be  lost  if 
recognizing  the  class  of  networks  produced  by  the  DL  were  as 
complex  a procedure  as  recognizing  deadlock  in  any  arbitary 
network  of  modules.  This  is  not  the  case.  The  advantage  would 
also  be  lost  if  the  class  of  networks  produced  by  the  DL  were 
not  general  enough  to  include  types  of  control  structures 
commonly  found  in  digital  systems.  Neither  is  this  the  case. 

The  plan  of  the  report  is  as  follows.  Section  2 defines  the 
DL's  syntax  and  gives  an  interpretation  of  that  syntax  by  using 
the  notion  of  a process.  The  syntax  is  an  improvement  of  that 
found  in  [Pet].  Recognition  of  potential  deadlock  has  been  made 
easier,  and  so  has  recognition  of  the  class  of  networks  produced 
by  the  DL.  This  has  been  achieved  without  reducing  the  class  of 
CSs  that  the  DL  can  describe.  Section  3 defines  the  modules  that 
the  DL  translates  onto.  These  are  the  So  (source)  module,  the  Si 
(sink)  module,  the  N (wye)  module,  the  S (sequence)  module,  the 
J (junction)  module,  the  SR  (shared  resource)  module,  the  D 
(decode)  module  and  the  1 (iterate)  module.  They  are  discussed 
at  length  in  the  literature  [Alt,  Bru]  and  have  been  used  in 


behavior  remains  unchanged,  when  any  number  of  delay  elements  is 
inserted  into,  or  removed  from,  any  of  the  two  lines  in  the 
links. 

1.  A network  of  modules  which  communicate  over  bidirectional 
links,  as  above,  deadlocks  when  at  least  one  of  the  links  in  the 
network  reaches  a state  of  having  a permanent  request  signal  on 
it,  which  is  not  the  result  of  a circuit  failure  in  a module  or 
link. 


paper  designs  to  illustrate  their  suitability  as  building  blocks 
in  the  design  of  CSs  of  complex  digital  systems  [DenJ.  Section 
4 describes  the  translation  procedure,  which  relates  the  modules 
and  the  syntax  oi  the  DL.  Section  5 shows  the  design  of  a simple 
digital  system  using  the  DL.  Section  6 examines  the  scope  of 
the  DL  and  shows  it  to  be  capable  of  describing  machines  having 
all  of  the  capabilities  normally  required  of  a microcontroller , 
as  well  as  the  capability  to  describe  the  control  of  parallel 
processes  without  the  unnecessary  binding  of  processes  to  one 
another  that  is  demanded  by  a synchronous  environment.  Section 
7 shows,  in  a quantitative  way,  that  the  computational 
complexity  of  an  algorithm  required  to  check  a design  in  the  DL 
for  correct  syntax  and  absence  of  deadlock  is  of  a lower  degree 
than  that  required  to  check  an  arbitary  network  of  modules  for 
absence  of  deadlock.  (From  sections  6 and  7 the  advantages  of 
using  a good  DL  may  be  inferred.)  Finally  section  b gives  a 
brief  summary  of  the  design  approach  developed  in  this  report. 


2. A DESIGN  LANGUAGE 


The  notion  of  a process  is  useful  in  discussing  the 
interpretation  of  the  DL,  before  explicit  reference  is  made  to 
the  modules.  In  this  report  the  term  "process'-  is  used  in  the 
following  way:  a process  in  a digital  system  is  some  activity 
that  is  initiated  by  placing  a request  signal  on  some  link  in 
the  CS  of  the  system  and  that  signals  its  completion  by  placing 
an  aknowleage  signal  on  the  link. 

Ihe  action  of  a CS  can  therefore  be  viewed  as  a complex 
process  which  decomposes  into  successively  less  complex 
processes  until  the  atomic  (indivisible)  process,  the  register 
transfer,  is  reached. 

This  hierachical  way  of  looking  at  CSs  conforms  to  the 
block-  structured  nature  of  the  DL.  By  using  the  DL  in  the 
design  procedure,  the  CS  produced  for  the  target  system  is  a 
network  of  modules  organized  as  a hierachy  of  sub-networks 
(represented  by  blocks  in  the  DL)  which  communicate  with  one 
another  over  single  links.  Thus,  for  any  two  subnetworks  joined 
by  a link  the  ''higher"  one  (the  one  that  puts  a request  on  the 
link)  can  view  the  ''lower''  one  (the  one  that  puts  an  acknowledge 
on  the  link)  as  a process.  Its  detailed  specification  can  then 
be  deferred  to  a convenient  point  in  the  design  procedure. 

The  DL  makes  use  of  three  types  of  blocks  to  describe 
complex  processes.  These  blocks  are  composed  of  two  types  of 
statements  (see  the  syntax  diagram,  figure  2.1)  . 


2. 1 The  Two  Statement  Types, 

The  two  types  of  statements,  process  call  (PROC-CALL)  and 
register  transfer  (REG-TRF),  are  illustrated  in  the  block  of 
statements  shown  in  figure  2.2.  Their  syntax  is  shown  in 
production  6 of  the  syntax  diagram. 

Statements  1 and  3 are  REG-TRF  type.  They  represent  links 
out  of  the  CS  to  register  transfer  points  in  the  DS , over  which 
requests  for  and  acknowledgments  of  register  transfers  pass.  In 
statement  1 of  this  example  the  control  of  the  register  transfer 
''move  the  contents  of  the  register  named  SOURCE  to  that  named 
DEST"  is  indicated.  Similarly  for  statement  3.  Both  statements 
are  atomic  processes  of  the  CS  being  described. 

Statements  2 and  4 are  PROC-CALL  type.  They  represent 
internal  links  of  the  CS  over  which  one  subnetwork  controls 
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Production  No. 


1.  Program 


2.PROC 


3.DPROC 


4.WPR0C 


(S)— »|PROC-ID  H WSTAT 


S TAT- LIST 


Figure  2.1.  The  Syntax  Diagram  (First  of  six). 
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5.STAT-LIST 


7.PR0C-CALL 


8.REG-TRF 


Figure  2.1.  The  Syntax  Diagram  (Second  of  six). 


9.  DSTAT 


1 

1 ^ 

NBITS 

K2) 

ACTION 

1 ^ 

11  WSTAT 


■{£)-< 


WHILE 


PRED 


12.PRED 


NAME|— ► REL  — ( } 

MnameI-^ 


Figure  2.1,  The  Syntax  Diagram  (Third  of  six) 


16.  LABEL 


17.NUM 


FP-4*6i 


Figure  2.1.  The  Syntax  Diagram  (Fourth  of  six). 


24.  REL 


'useful  binory  relotions^^ 


rP«95S 


Terminal  symbols  are  enclosed  in  circles  or  boxes  with  round 
ends.  Non-terminal  symbols  are  enclosed  in  rectangles.  Those 
terminal  symbols  that  are  spelt  differently  in  the  text  are 
listed  below  together  with  their  spelling. 


DL  carriage  return,  line  feed. 

LETTER  A,...,Z. 

DIGIT  0,...,9. 


Blanks  may  be  inserted  between  terminals 
reading;  they  are  ignored  by  the  syntax  analyser. 


for  ease  of 


Figure  2.1.  The  Syntax  Diagram  (Sixth  of  six). 


another.  In  statement  2 the  control  of  a subnetwork  identified 
as  BLOCKS  by  BLOCK!  is  indicated. 

BLOCK!  is  an  example  of  a complex  process,  which  decomposes 
into  two  atomic  processes  (statements  ! and  3)  and  two  other 
less  complex  processes  BL0CK2  and  BLOCKS  (statements  2 and  4). 
The  order  in  which  these  four  processes  are  to  occur  is 
indicated  in  the  DL  by  the  parenthesized  integers  to  the  right 
of  the  statements  (termed  OHDEH-INFO  in  the  syntax  diagram).  The 
directed  graph  farther  right  illustrates  pictorially  how  the 
order  information  is  to  be  interpreted. 


2.2  The  Three  Block  Types. 

The  three  types  of  blocks,  a process  block  (PROC),  a 
decision  making  process  block  (DPROC),  and  an  iterative  process 
block  (WFROC)  are  illustrated  in  figure  2. 3. Their  syntax  is 
shown  in  proauctions  2 thru  4 of  the  syntax  diagram.  P is  a PROC 
type,  D is  a DPROC  type  and  I is  a WPROC  type  block. 

The  PROC  type  block  is  used  to  represent  a complex  process 
which  decomposes  into  other  prossess  denoted  by  the  block's 
statements.  Both  types  of  statements  may  be  used,  so  the 
constituent  processes  of  a PROC  block  may  be  atomic  or  complex. 

The  DPROC  type  block  is  used  to  represent  a branch  point  in 
the  CS.  Depending  on  the  value  of  some  variables  external  to  the 
CS,  control  is  switched  to  one  of  a set  of  blocks  listed  in  the 
DPROC.  These  blocks  may  be  any  of  the  three  types. 

The  RPROC  type  block  represents  a complex  process  that  is 
only  initiated  if  some  predicate  external  to  the  CS  is  true. 
Upon  its  completion  the  process  is  reinitiated  if  the  predicate 
is  still  true.  Reinitiation  continues  as  long  as  the  predicate 
remains  true. 

A clearer  idea  of  the  processes  that  can  be  represented  by 
the  three  block  types  may  be  got  by  examining  figure  2.3  more 
closely. 

Figure  2.3(a)  shows  a PROC  type  block  named  P which 
represents  the  following  complex  process:  when  the  process  P is 
requested,  A is  initiated  together  with  the  register  transfer 
action  D<-  S (move  the  contents  of  register  S to  register  D). 
When  A is  completed  process  B is  to  be  initiated.  When  both  D<-  S 
and  B are  completed  process  A is  to  be  reinitiated  . Finally 
with  the  completion  of  A,  process  P is  considered  completed  and 
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1)  A 

2) B  (1) 

3)  D^S 

4)  A (2,3) 
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Figure  2.3(a). 
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NONE=>  COMPLETE 


Figure  2.3(b), 
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WHILE  X=1  DO 

1)  A 

2) DI-^S1  (1) 

3) D2-^S2  (1) 

FP-4993 


Figure  2.3(c).  Further  Example  Blocks. 
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an  aknowledge  signal  is  sent  along  the  link  controlling  F.  Ihe 
directed  graph  to  the  right  of  the  block  illustrates  the 
ordering  of  the  constituent  processes  of  P.  (Notice  block  BLOCK' 
of  figure  2.2  was  an  example  of  a PROC  type  block.)  The 
processes  identified  by  A and  B may  themselves  be  complex  and 
will  be  represented  by  one  of  the  three  block  types.  They  stand 
in  the  same  relation  to  P as  P does  to  the  complex  process  that 
"calls"  it. 

Figure  2.3(b)  shows  an  example  of  a DPROC  type  block.  This 
indicates  how  the  control  is  to  branch  according  to  the  state  of 
some  external  variables  (X).  If  xO  V x1  = 0 then  the  process 
represented  by  the  block  A is  to  be  initiated.  Upon  its 
completion  the  process  represented  by  D is  considered  completed 
and  control  passes  back  to  the  calling  process.  The  reserved 
word  NONE  stands  for  the  union  oi'  all  those  conditions  of  the 
external  variables  not  explicitly  listed  (i.e.  xO  v xl  = 1).  The 
reserved  word  COMPLETE  indicates  that  if  NONE  is  true  the  empty 
process  is  to  be  completed,  in  other  words,  that  control  is 
returned  directly  back  to  the  calling  process. 

Figure  2.3(c)  snows  an  example  of  a WPROC  type  block.  If 
the  predicate  x = 1 is  false,  then  the  empty  process  is  to  be 
completed.  If  the  predicate  x = 1 is  true,  then  process  A is  to 
be  initiated  and  when  it  is  completed  the  register  transfer 
processes  D'K-  SI  and  D2<- S2  are  both  to  be  initiated.  When  they 
are  both  completed  the  whole  block,  starting  with  A,  is  to  be 
reinitiated  as  long  as  the  predicate  is  true.  As  soon  as  the 
predicate  is  no  longer  true,  and  both  D'i<-  S'!  and  D2^  S2  have 
been  completed,  the  process  represented  by  I is  then  considered 
completed.  Control  passes  back  to  the  calling  process. 


2.3  Comments  On  The  Syntax. 

The  similarities  between  the  DL  and  a procedure  oriented 
language  such  as  Algol  are  obvious.  Both  may  be  thought  of  as 
representing  computational  processes,  and  both  translate  into 
machines  that  realize  those  processes.  Nevertheless  there  are 
several  important  differences.  First,  there  is  no  parameter 
passing  by  the  PROC-CALL  type  statements  (this  would  be 
analagous  to  subroutine  parameter  passing).  This  was  done  for 
simplicity  and  there  is  no  conceptual  reason  why  the  DL  could 
not  be  extended  to  incorporate  this  facility.  Parameters  could 
be  registers,  then  a block  could  be  shared  by  several  similar 
processes  which  operate  on  different  registers.  (The  translator 
would  have  to  add  switches  to  the  DS,  so  that  different  sections 
of  the  DS  could  be  switched  to  the  same  section  of  the  CS  for 


processing.)  Second,  the  DL  explicitly  indicates  the  order  in 
which  processes  are  to  be  initiated,  whereas  a procedure 
oriented  programming  language  assumes  a serial  operation  of  the 
processes  represented  by  its  statements,  modified  only  by  branch 
statements.  Finally,  the  DL  does  not  have  a defined  data  set  nor 
are  any  data  operators  defined.  These  should  be  suggested  by 
the  particular  requirements  of  the  target  system. 


I 

I 

I 

I 

I 

I 
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3.  THE  MODULES 


) show  how  the  DL  translates  onto  a set  of 
is  necessary  to  define  the  modules  more  orecisely. 

asynchronous  modules  have  been  proposed 
LCla,  Kel],  The  set  defined  below  was  chosen  because  its 
members  have  a natural  correspondence  with  the  DL. 
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Each  module  is  formulated  with  the  aid  of  a state  diagram, 
alter  the  style  of  Keller  [Kel],  In  this  formulati 
are  aelinea  at  the  level  of  signal  behavior.  If  ti 
to  be  built  some  decision  on  the  signalling  conver 
request  and  the  acknowledge  signJ 
flow  tables  could  be  constructed  and 
modules  could  be  completed.  (Figure  3.1  shows  three  of  the  most 
common  signalling  conventions, ) 

The  design  of  the  modules  has  been  completed  for  some 
signalling  conventions.  Patil  has  presented  designs  for  the 

Lmpler  n 

NOl  gate,  the  EXCLUSIVE-OR  gate  and  the 


(This  is  a consequence  of 


the  module  set  [Pet]  using 
signalling.  These  are  fault- 
on  their  links.  (This  is  a cc 
than  the  signalling  convention 
links. ) No  designs  for  the  module  set  are  known  to  the  author 
which  use  other  signalling  conventions.  Were  such  sets  desired 
the  design  approach  presented  in  [Kel]  deserves  consideration. 
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3. T Ihe  Source  Module. 

The  source  (So)  module  is  shown  in  figure  3.2 
is  a diagrammatic  representation.  It  has  one  output 
arrows  on  links  are  always  shown  in  the  direc 
request  signal  travels.  ) Operation  of  the  module  is 
state  diagram  to  the  right.  The  arcs  of  the  stat 
labelled  as  follows:  input  signal  / set  o 

outputsignals.  The  occurrence  of  a request  signal 
R,  an  acknowledge  signal  by  A.  (In  later 
subscripts  are  used  to  indicate  the  link  to  whi 
belongs. ) From  the  state  diagram  it  can  be  seen  tha 
transmits  a reauest  signal  whenever  an  acknowle 
received.  It  thus  acts  as  a source  of  requests. 


. On  the  left 
link.  (The 
tion  that  the 
shown  by  the 
e diagram  are 
f resulting 
is  denoted  by 
sub-sections 
ch  the  signal 
t the  module 
dge  signal  is 
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Figure  3.1.  Some  Signalling  Conventions. 
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Figure  3.2.  The  Source  Module. 
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Figure  3.3.  The  Sink  Module. 
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3.2  The  Sink  Module. 


The  sink  (Si)  module  is  shown  in  figure  3-3.  In  operation  it 
complements  the  So  module.  Whenever  it  receives  a request  signal 
it  transmits  an  acknowledge  signal.  It  thus  acts  as  a sinK  for 
requests. 


3.3  The  Wye  Module. 

The  wye  (W)  module  is  shown  in  figure  3.^*  The  module  is 
initially  in  state  ' . (Initial  states  are  distinguished  by  a 
free  arrow  in  the  state  diagram.)  When  a request  is  received  on 
link  1 , requests  are  transmittea  on  links  2 and  3 both.  When  an 
acknowledge  signal  is  received  on  both  links  2 and  3 (in  any 
order)  an  acknowledge  is  transmitted  on  link  1.  Thus  a W module 
may  be  used  by  a process  to  simultaneously  initiate  two  other 
processes.  Onlv  when  both  of  these  processes  are  completed  (i.e. 
when  the  module  has  received  acknowledge  signals  on  links  2 and 
3)  is  the  calling  process  notified  by  the  transmittal  of  an 
acknowledge  along  link  1. 

The  function  A,  shown  to  the  right  of  the  state  diagram, 
places  constraints  on  the  way  the  module's  environment  acts  on 
it.  For  any  state  q of  the  module  A(q)  £ P[l]  represents  the 
allowable  input  sets  (F[I]  is  the  power  set  of  all  possible 
inputs,  I).  If  S <•  A(q)  then  any  subset  of  the  lines 
corresponding  to  the  elements  of  S is  allowed  to  be  signalled 
concurrently.  Hence  in  state  2 inputs  A2  and  A3  can  be  signalled 
concurrently.  It  is  assumed  that  this  and  all  other  modules  that 
can  receive  concurrent  signals  choose  to  assimilate  the  signals 
one  at  a time  in  an  arbitrary  order.  Tne  state  diagram  then 
exhibits  the  required  behavior. 


H 


3.^4  The  Sequence  Moaule. 

The  sequence  (S)  module  is  shown  in  figure  3.5.  The  module 
is  initially  in  state  ”.  When  a request  is  received  on  link  1 a 
request  is  transmitted  on  link  2.  When  an  acknowledge  xs 
received  on  link  2 a request  is  transmitted  on  link  3-  Finally 
an  acknowledge  on  link  3 causes  an  acknowledge  to  be  transmitted 
on  link  1.  Thus  the  S module  may  be  used  by  a process  to 
initiate  two  processes  one  after  the  other.  The  calling  process 
requests  on  link  1 whereupon  the  process  controlled  by  link  2 is 
performed.  On  its  completion  the  process  controlled  by  link  3 is 
performed,  and  an  acknowledge  is  returned  to  the  calling 
process. 


1 


Ri 


R2.R3 


A(2)={{A2,A3}} 

A(3)={{A2}} 

A(4)={{A3}} 


Figure  3.^.  The  Wye  Module, 


Figure  3-5.  1 he  Sequence  Module. 
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3.5  The  Junction  Module. 


The  junction  (J)  module  is  shown  in  figure  3.6,  Its 
operation  can  be  viewed  as  the  dual  of  the  Vj  module.  It  may  be 
used  by  two  calling  processes  to  initiate  a third  process.  The 
calling  processes  request  over  links  I and  2.  The  third  process 
is  controlled  by  link  3,  and  is  not  initiated  until  both  the 
calling  processes  have  requested  it.  The  module  thus  performs  an 
act  of  synchronization  between  two  concurrent  processes,  before 
initiating  a third.  When  the  called  process  is  completed  it 
broadcasts  an  acknowledge  to  both  the  calling  processes. 


,6  The  Shared  Resource  Module, 

The  shared  resource  (SR)  module  is  shown  in  figure  3.7.  It 
can  be  thought  of  as  a module  for  allowing  two  processes  to 
share  some  other  process. 

If  a request  is  received  on  link  ' then  the  process 
controlled  by  link  3 is  initiated.  When  this  is  completed  an 
acknowledge  is  received  on  link  3 and  an  acknowledge  is 
transmitted  along  link  1,  Similarly  if  the  request  is  received 
on  link  2,  Thus  either  the  calling  process  which  controls  link  ’ 
or  the  process  which  controls  link  2 can  gain  control  of  the 
process  controlled  by  link  3.  If  requests  on  links  1 and  2 
overlap  (i,e,  requests  occur  on  links  1 and  2 without  an 
intervening  acknowledge  on  link  3)  they  are  still  handled  in  the 
order  in  which  they  arrive.  If  they  occur  simultaneously  (as 
they  can;  see  A(1))  they  are  handled  in  arbitrary  oraer. 
Similarly  if  a request  arrives  on  an  input  link  simultaneously 
with  an  acknowledge  from  the  process  controlleo  by  link  3. 


3.7  The  Decode  Module, 

The  decode  (D)  module  is  shown  in  figure  3.6.  A calling 
process  requests  on  link  1.  This  request  is  transmitted  on  link 
3 or  2 depending  on  whether  the  external  variable  x is  true  or 
false.  The  acknowledge  is  returned  in  the  usual  manner.  Thus  the 
D module  may  be  used  as  a branch  point  in  a CS.  The  branch  taken 
is  controlled  by  the  logical  value  of  x. 

In  figure  3.8  the  link  used  to  test  the  value  of  x is  shown 
as  a bundle  of  three  broken  lines.  It  is  depicted  in  more  detail 
than  normal  links,  because  it  carries  three  signals  rather  than 
the  normal  two.  A signal  is  transmitted  on  line  0 to  test  the 
external  variable  x and  is  returned  on  either  Ij  or  Ip 
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depending  on  vjhether  x is  true  or  lalse.  The  testing  occurs 
every  time  the  module  receives  a request  on  link  1. 

As  a final  point,  notice  the  constraint  on  the  environment 
described  by  A(2).  Since  x can  take  on  only  one  value  at  a time, 
this  constraint  shoula  be  trivially  satisfied. 


3.b  Ihe  Iterate  Module. 

The  iterate  (1)  module  is  shown  in  figure  3.9.  A calling 
process  reouests  on  link  “ . If  the  external  predicate  P is  false 
an  acknowledge  is  transmitted  back  along  link  1.  If  P is  true 
the  process  controlled  by  link  2 is  initiated  by  transmitting  a 
request  on  link  2.  When  it  is  completed  an  acknowledge  is 
received  on  link  2,  and  if  P still  remains  true  a request  is 
retransmitted  on  link  2 reinitiating  the  process  controlled  by 
link  2.  This  reinitiation  continues  as  long  as  P is  true.  If  an 
acknowledge  is  received  on  link  2 when  P is  false  the  process 
controlled  by  link  2 is  no  longer  reinitiated.  Instead  an 
acknowledge  is  transmitted  on  link  * back  to  the  calling 
process.  Notice  the  predicate  testing  link  is  shown  in  greater 
detail,  as  it  was  in  the  section  on  the  D nodule.  This  module 
may  be  used  in  a CS  when  a process  is  required  to  be  reinitiated 
as  long  as  some  external  predicate  holds. 


3.9  Comments  On  The  Modules. 

Figure  3.10  shows  some  notational  aids  used  in  subsequent 
sections.  S nodules  are  shown  as  at  the  top  of  the  figure;  the 
links  numoered  2 and  3 in  section  3.^  are  called  the  primary  and 
secondary  links,  and  the  primary  link  is  distinguished  by  a 
circle  at  its  base.  D modules  are  shown  as  in  the  center  of  the 
figure;  tne  link  with  the  circle  at  its  base  is  the  one  that 
relays  control  if  the  variable  x is  false.  I modules  are  shown 
as  at  the  bottom  of  the  figure;  where  P denotes  the  predicate. 
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A(3)={{A2}} 
A(4)  = {{A3}} 


igure  3.6.  The  Decode  Module. 


A(1)={{r.}} 
A(3)  = {{A2}} 
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Figure  3*9.  The  Iterate  Module. 
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THE  TRANSLATION  PROCEDURE 


A procedure  is  presented  below  that  translates  descriptions 
in  the  DL  into  networks  of  modules.  Thus  for  each  description  in 
the  DL  there  exists  an  asynchronous  machine  that  is  uniquely 
determined  by  the  syntax  (defined  in  the  syntax  diagram  of 
section  2),  the  translation  procedure  below  and  the  state 
diagrams  that  define  the  modules  in  section  3. 


The  behavior  of  these 
with  the  informal  interprets 
syntax  diagram  in  section  2 
the  behavior  of  the  modules 
section  3. 

The  translation  procedur 
from  figure  4.1.  Each  o 
shown  again,  this  time  along 
PhOC  blocks  translate  to  ne 
blocks  translate  to  trees 
translate  to  networks  of 
module. 


asynchronous  machines  is  consistent 
tion  of  the  DL  accompanying  tne 
, and  the  informal  interpretation  of 
accompanying  the  state  diagrams  in 


e is  quite  simple,  as  can  be  deduced 
f the  three  blocks  in  figure  2.3  is 
side  of  its  modular  realization, 
tworks  of  W,  S,  and  J modules,  DPROC 
of  D modules,  and  WPROC  blocks 
W,  S and  J moaules  headed  by  an  1 


The  translation  procedure  partitions  naturally  into  two 
phases:  determining  the  intra-block  connections  of  the  modules, 
and  determining  the  inter-block  connections  of  the  modules. 


4.1  The  Intra-Block  Connections. 

In  the  case  of  PROC  and  WPROC  blocks  the  intra-block 
connections  of  W,  S,  and  J modules  are  deduced  from  their  intra- 
block matrices.  Examples  of  these  are  also  shown  in  figure  4.1. 
These  matrices  are  derived  directly  from  the  order  information. 
If  m denotes  the  intra-block  matrix  of  a block,  then  m(i,j)  = 
iff  the  statement  labelled  i in  that  block  has  the  integer  J in 
its  order  information.  The  matrix  can  be  interpreted  to 
represent  the  binary  relation  "is  the  successor  of  ".  Then 
m(i,j)  = 1 indicates  that  the  statement  labelled  i "is  the 
successor  of"  the  statement  labelled  j.  In  every  PROC  and  WPROC 
block  there  should  be  at  least  one  statement  which  is  not  the 
successor  of  any  other  in  tnat  block;  it  is  distinguished  by 
having  no  order  information.  To  complete  the  matrix  a dummy 
statement  is  assumed  which  precedes  such  statements.  (In  the  two 
examples  of  the  figure,  the  dummy  statements  are  labelled  0,  but 
they  need  only  be  labelled  distinctly. ) 


Once  the  intra-block  matrix  of  a block  has  been  found  an  S 
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module  is  allocated  to  each  statement  in  the  block,  except  to 
dummy  statements  and  those  having  no  successors.  (A  statement  j 
has  no  successors  iff  m(i,j)  = 0 •¥  i.)  for  each  statement  i,  a 
tree  of  (n  - 1)  J modules  is  allocated  to  i iff  m(i,j)  = n. 
If  i has  already  been  allocated  an  S module,  its  input  link  is 
connected  to  the  output  link  of  the  J tree.  Similarly  for  each 
statement  j,  a tree  of  ( n - * ) k modules  is  allocated  to  j iff 
m(i,j)  = n.  If  j has  already  been  allocated  an  S module,  its 
secondary  output  link  is  connected  to  the  input  link  of  the  W 
tree.  At  this  point  each  statement  has  been  allocated  a star 
shaped  network  of  modules.  This  star  comprises  a J tree 
connected  to  an  S module,  which  is  connected  to  a W tree.  In 
general  these  stars  may  be  degenerate,  and  have  any  of  the  forms 
shown  in  figure  4.2,  or  in  the  most  degenerate  case  no  modules 
at  all.  The  final  step  in  determine  the  intra-block  connections 
is  made  directly  from  the  matrix.  If  m(i,J)  = 1 then  an  output 
link  of  the  star  allocated  to  statement  j is  connected  to  an 
input  link  of  the  star  allocated  to  statement  i.  In  this  way 
each  statement  becomes  associated  with  a unique  output  link.  In 
the  case  of  those  statements  which  are  allocated  an  S module 
this  link  is  the  primary  output  link  of  the  S module.  In  the 
case  of  statements  with  no  successors  this  link  is  either  one 
output  of  the  star  allocated  to  its  predecessor  (whence  it  would 
be  the  secondary  output  of  an  S module  or  the  output  of  a W 


module),  or  the  output  link  of  a J tree, 

Ihe  important  point  to  notice  about  the  structure  of  blocks 
formed  in  this  way  is  that  they  only  have  a single  input  link 
and  that  no  intra-block  connections  involve  the  primary  output 
links  of  S modules. 

In  the  case  of  WPhOC  blocks  the  output  link  of  an  I module 
is  connected  to  the  input  link  of  the  block,  to  complete  the 
intra-block  translation. 

In  the  case  of  DPROC  blocks  a tree  of  D modules  is  allocated 
as  follows.  The  argument  of  the  DECODE  statement  is  a name  (see 
production  9 of  the  syntax  diagram)  , which  represents  a string 
of  external  bit  variables.  If  there  are  n bits  in  the  string  tne 
tree  needs  to  be  n levels  deep.  The  first  bit  is  tested  by  the 
top  D module,  the  second  by  the  two  D modules  on  the  second 
level  of  the  tree,  and  so  on  to  the  n-th  level.  Each  directed 
path  thru  the  D trees  links  corresponds  to  a unique  value  tor 
the  bit  string.  Those  oaths  which  correspond  to  a COMPLETE 
action  (see  productions  10  and  21  in  the  syntax  diagram)  are 
terminated  with  an  Si  module.  Any  D module  with  both  output 
links  connected  to  Si  modules  as  a result  of  this  can  be 
replaced  by  an  Si  module. 


4,2  Inter-Block  Connections. 

Inter-block  connections  are  determined  in  a manner  similar 
to  the  intra-block  connections.  They  are  deduced  from  the  inter- 
block matrix  M.  A fragment  of  such  a matrix  is  given  in  figure 
4.3,  showing  the  inter-block  connections  of  a series  of  blocks, 
one  of  which  is  the  PROC  block  in  figure  4,1.  This  matrix  is 
derived  directly  from  the  block  identifiers,  the  PROC-CALL  type 
statements,  and  the  DLIST  actions  which  are  PROC-IDs.  M(i,j)  = k 
iff  block  J has  k PROC-CALL  type  statements  whose  PROC-ID  is  i, 
or  (in  the  case  of  J being  a DPROC  block)  k DLIST  actions  whose 
PhUC-lD  is  i.  (Note  that  i and  j are  no  longer  necessarily 
integers;  they  may  be  alphameric  strings,)  As  before  the  matrix 
can  be  interpreted  to  represent  the  binary  relation  '-is  the 
successor  of'-. 

If  M(i,j)  = 1 then  the  output  link  of  block  j,  which  is 
associated  with  the  statement  or  DLIST  action  whose  PROC-ID  is 
i,  is  connected  to  the  input  link  of  the  block  with  identifier 
i.  If  Zj  M(i»j)  = n (n>1)  more  than  one  block  output  link 
connects  to  the  input  of  block  i.  This  is  done  with  a tree  of 
(n  - 1)  SR  modules.  If  M(i,J)  = 0 then  block  i has  no 
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figure  4.3.  An  Example  Of  An  Inter-Block  Matrix. 

predecessors,  and  its  input  link  must  be  capped  with  a So 
module. 

finally,  register  transfers  may  in  general  be  shared,  in 
other  words  the  same  fiEG-TBF  type  statement  occurs  more  than 
once.  This  can  be  deduced  from  an  auxiliary  inter-block  matrix 
M'.  M'(i,j)  = k iff  block  j contains  k REG-TRF  statements  i.  If 

H'(i,j)  = n (n>1)  then  the  register  transfer  i is  shared 
using  a tree  of  (n  - 1)  SR  modules  as  before. 


4.3  Comments  On  The  Translation  Procedure. 

The  intra-block  matrices  together  with  the  inter-block 
matrix  and  auxiliary  inter-block  matrix  may  also  be  used  to 
check  that  the  network  of  modules  does  not  contain  potential 
deadlock  [Mud]. 


N.B.  Read  SR  for  U in  Figures  4.1,  4.3  and  5.3. 
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5.  AN  EXAMPLE  USING  THE  DL 


The  design  example  presented  nere  is  a single  instruction 
computer  called  SIM  (Sinele  Instruction  Machine)  wnich  performs 
tne  single  three  address  instruction  SUB'iST  A,  B,  P.  The 
operation  of  this  instruction  is  equivalent  to  the  two 
instructions ; 


1.  A ^ C(A)  - C(B) 

2.  IF  c(A)  = 0 Then  pc  ^ C(P) 

(PC  is  the  program  counter,)  Its  control  structure  is  described 
in  the  DL  below. 


SIM 

WHILE 

PUN  = 

' DO 

Comments . 

1 . 

DECI 

This  is  the  basic  instruction 

2, 

FETCH 

( 1 

\ 

) 

fetch  and  execution  cycle. 

It 

3. 

EXEC 

(2 

) 

continues  as  long  as  the 

RUN 

button  is  on.  Furthermore 

the 

block  DECI  tests  the  interrupt 

flag  before  each  cycle. 

DECI 

INT  is  the  interrupt  flag.  If 

' it 

DECODE  INT  as 

is  on  (=1)  the  interrupt 

i s 

1 => 

INTR 

handled  by  block  INTR, 

0 => 

COMPLETE 

INTR 

INTR  handles  the  interrupt. 

IPA 

' • 

har  <- 

IPA 

holds  the  address  at  which 

the 

2. 

DR  <- 

IP 

interrupting  data  is  to 

be 

3. 

M <-  DR 

( 1 ,2) 

stored.  The  interrupt  is  only 

for 

inputting  data. 

FETCH 

This  is  the  FETCH  routine.  MAH 

is 

1 . 

MAR  <- 

PC 

the  memory  address  register. 

PC 

2. 

DH  <- 

M 

(1) 

is  the  program  counter.  DH  is 

the 

3. 

PC  ^ 

INC 

( )) 

data  register;  it  holds  the  data 

input  to  and  output  from  M. 

INC 

is  the  incrementing  unit, 
output  is  its  input  plus  one. 

Its 

EXEC 

This  executes  the  three  address 

1 . 

IR  <- 

DR 

instruction.  !«  is 

the 

2. 

MAR  X- 

IRA 

(1) 

instruction  register.  It  is  split 

3. 

Dh  <- 

M 

(2) 

into  three  subfields,  IRA  holds 

4. 

hh'i 

DR 

(3) 

the  address  A,  and  IBA  holds 

the 

5. 

A <-  DR 

(3) 

address  B.  The  REG-TRF  statements 
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b. 

MAh  IRB 

(3) 

4 and  10  are  links  out  of  the  CS 

7. 

DR  M 

(4,5,6) 

(Dhl  and  DR2  are  dummy  registers) 

0. 

Dh  <-  SUB 

(7) 

which  indicate  to  the  external 

9. 

MAR  <r  IRA 

(7) 

environment  that  DR  is  loaded 

■iO. 

Dh2  ^ DR 

(b) 

with  data  which  could  be  accessed 

1 * • 

M <r  DR 

(8,9) 

by  some  external  device. 

“2. 

DEC 

( 10,  I *) 

DEC 

DEC  checks  to  see  if  the  result 

DECODE  Dh  AS 

of  the  subtraction  is  zero.  If  it 

0, . . 0 =>  Bh 

is,  block  BR  is  initiated. 

NONE  =>  COMPLETE 

&R 

IRP  holds  the  branch  address. 

1 , 

Dh  <-  PC 

C(PC)  is  loaded  at  the  branch 

2. 

PC  <-  IRP 

(1) 

address  and  PC  is  loaded  with  the 

3. 

MAR  PC 

(2) 

branch  address. 

4. 

M Dh 

(3) 

5. 

PC  INC 

(3) 

END 

The  resulting 

DS  is 

shown  in  figure  5.1.  The  lines 

connecting  the  registers  represent  buses,  and  the  slashes  at  the 
bus  intersections  represent  identity  operators.  The  one  shown  in 
figure  5.''  next  to  the  letter  I moves  data  from  the  program 
counter  to  the  memory  address  register  when  reouested  to  do  so 
by  the  3 module  corresponding  to  the  DL  REG-TRF  statement  ''MAR 
PC’*  (see  FETCH  block  statement  1),  The  block  structure  of  the 
design  is  shown  in  figure  5.2,  and  tne  modular  realization  of 
the  CS  is  shown  in  figure  5.3.  (In  this  figure  FETCh(2) 
indicates  a link  from  statement  2 of  block  FETCH. ) 


When  a CS  is  hooked  up  to  a particular  DS  the  determinism  of 
tne  total  system  must  be  verified.  The  presentation  of  a 
systematic  method  to  check  for  determinism  is  outside  the  scope 
of  this  report.  In  the  above  example  the  determinism  was  checked 
by  visual  examination  of  the  REG-TRF  statements  in  the  DL 
description.  (This  could  clearly  be  inadequate  in  a much  larger 
design . ) 
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EXEC 


6.  THE  SCOPE  OF  THE  DL 


Tne  Droposed  design  methodology,  outlined  in  the 

Introduction,  was  to  view  digital  systems  as  modular  structures 

which  partition  into  a CS  and  a DS.  The  design  of  various 
modules  could  then  be  performed  off  line,  as  it  were,  by 
conventional  means  and  the  design  task  would  then  reduce  to  the 
modular  design  of  the  CS.  It  is  this  task  which  the  DL  is  aimed 

at,  ana  consequently  it  is  with  respect  to  this  task  that  the 

scope  of  the  DL  is  examined. 

One  very  common  model  for  CSs  is  the  flowchart.  This  is 
evident  from  the  large  number  of  digital  systems  that  are 
controlled  by  microprogram.  Any  flowchart  can  be  represented  as 
an  expansion  of  the  following  constructs  [Mil]; 

1.  f THEN  g 

2.  IF  p THEN  f ELSE  g 

3.  WHILE  p DO  f 

where  f and  g are  flowcharts  with  one  input  and  one  output,  and, 
THEN,  If,  ELSE,  WHILE,  DO  are  logical  connectives.  If  the  term 
"flowchart'-  is  interpreted  as  "process''  (in  the  sense  of  section 
2),  the  following  consequences  arise:  f and  g can  be  interpreted 
as  processes  described  by  the  DL.  This  follows  since  such 
processes  are  controlled  by  a single  link,  and  hence  can  be 
thought  of  as  having  one  input  and  one  output  (the  request  and 
acknowledge  signals  of  the  link).  Furthermore,  the  above  three 
constructs  are  then  seen  to  occur  in  the  DL;  3 exists  explicitly 
the  WPROC  block,  2 exists  in  a more  general  form  - the  DPROC 
block,  and  1 also  exists  in  a more  general  form  - the  order 
information.  hence  the  scope  of  the  DL  encompasses  that  of  the 
flowchart  model,  as  well  as  allowing  the  additional  facility  of 
unrestricted  parallelism.  This  last  Qualification  refers  to  the 
fact  that  the  order  information  allows  parallelism  to  be 
described  without  unnecessarily  binding  processes  together,  as 
is  often  the  case  with  restricted  methods  of  representing 

parallelism,  such  as  the  use  of  NEXT  or  AND  operators  to  denote 
concurrency  [3ha,  BelJ.  (These  two  particular  operators  restrict 
a language  to  series/parallel  structured  processes, ) 

The  indefinite  extensibility  of  the  modular  approach, 
together  with  the  scope  that  the  DL  has  been  shown  to  possess, 

suggests  that  the  first  of  the  two  aims  stated  in  the 

introduction  (to  develop  a DL  for  large  digital  systems)  has 
been  satisfied.  Nevertheless  it  should  be  oointed  out  that, 
although  the  DL  is  capable  of  modeling  parallel  processes,  some 
processes  such  as  pipelined  processes,  overlapped  processes. 
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etc.,  (which  are  closely  related  to  parallel  processes)  are 
outside  the  scope  of  the  DL.  Such  capabilities  are  often 
required  when  a hiKh  performance  system  is  to  be  designed  [Den]. 

Finally  one  other  model  should  be  mentioned  in  passing.  This 
is  the  Petri  net  [Hoi],  and  it  is  a more  general  mooel  than  the 
llowchart.  It  can  describe  CSs  that  are  outside  the  scope  of  the 
DL,but  much  of  the  additional  scope  of  the  Petri  net  is  of 
questionable  use,  and  the  considerable  complexity  of  any  Petri 
net  that  models  a large  CS  can  confuse  rather  than  aid  the 
design  process. 
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7.  A QUANlllAUVE  LOOK  A7  THE  DL 


In  this  section  it  is  shown,  in  a quantitative  way,  that  the 
computational  complexity  of  an  algorithm  required  to  check  a 
design  in  the  language  for  correct  syntax  and  absence  of 
deadlock  is  of  a lower  degree,  than  that  required  to  check  an 
arbitary  network  of  modules  for  absence  of  deadlock.  Hence  it 
may  be  concluded  that  fault  free  design  using  the  DL  is  easier 
(from  a computational  complexity  view  point)  than  constructing  a 
CS  by  the  ad  hoc  interconnection  of  modules. 

Computational  complexity  analyses  are  concerned  with  the 
"amount  of  work"  done  by  algorithms.  Eor  the  purpose  of  this 
discussion  this  is  measured  in  terms  of  the  number  of  operations 
which  must  be  performed. 


7.1  The  Complexity  Of  Checking  The  Syntax  Of  A Design  In  The  DL. 

The  first  step  in  checking  the  syntax  of  a design  in  the  DL 
is  to  take  the  string  of  characters  representing  the  design  and 
to  oartition  it  into  a sequence  of  tokens,  where  a token  is  a 
string  of  characters  that  forms  a single  logical  unit. 

The  syntax  given  in  the  syntax  diagram  of  figure  2, 1 can  be 
simplified  if  the  following  logical  units  are  tokenized: 
identifiers,  decode  statements,  while  statements,  labels, 
register  transfers  and  bit  strings.  The  resulting  simplified 
grammar  is  shown  in  figure  7.1.  Notice  that  the  tokenized 
entities  are  now  represented  by  a single  generic  terminal 
symbol , 

Strings  of  symbols  produced  by  this  grammar  can  be  checked 
for  syntactical  correctness  by  the  finite  automaton  whose 
control  state  diagram  is  shown  in  figure  7.2.  (This  implies  the 
tokenized  DL  is  a regular  language,  although  it  is  not 
characterized  by  a regular  grammar,  as  can  be  seen  from  the 
simplified  grammar  of  figure  7.1.)  The  control  states  are  shown 
as  circles,  with  the  start  and  finish  states  labelled  S and  E 
respectively.  A string  is  accepted  as  syntactically  correct  if 
starting  in  state  S there  exists  a path  to  F such  that  the  arc 
labels  taken  in  the  order  in  which  they  occur  in  the  path  agree 
with  the  string.  Otherwise  the  string  is  considered  to  have  a 
syntax  error. 

For  any  input  string  no  input  symbol  is  examined  by  the 
above  parsing  procedure  more  than  once,  hence  any  input  string 
is  parsed  in  a number  of  operations  linearly  proportional  to  the 
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M 

-> 

PM'  1 DM 

M' 

-> 

b$  1 PM’ 

P 

-> 

baL 

D 

-> 

bad  A 

W 

-> 

bawL 

L 

-> 

blSL’ 

L* 

-> 

It  1 blSL 

S 

-> 

al  1 r I 

I 

-> 

If  1 (X) 

X 

-> 

n 1 n ,X 

A 

-> 

bkaA ' 

A* 

-> 

It  1 bkaA 

I 

I 

I 

I 


Non-Terminals 


Equivalent  In  Syntax  Diagram 


M, 

P 

D 

W 

L, 

S 

1 

A, 

X 


M’ 


L’ 


A’ 


PROGRAM 

PROC 

DPROC 

WPROC 

SlAl-LIST 

ST  AT 

ORDER-INPO 

DEIST 

SUB-LIST 


Terminals 


I 

I 

f 

f 

I 


b 

$ 

a 

d 

w 

1 

# 

r 

n 

k 


DL 

END 

tokenized  identifiers 
tokenized  DSTATs 
tokenized  WSTATs 
tokenized  LABELS 
null  string 
tokenized  REG-TRFs 
tokenized  NUMs 
tokenized  BITS  =>  s 


Pigure  7.1.  The  Simplified  Grammar. 


length  of  the  input  string.  Thus  an  algorithm  for  checking  any 
design  in  the  DL  for  syntactical  correctness  need  not  have  a 
complexity  of  greater  than  0(n),  where  n is  the  number  of 
statements  in  the  design. 

It  might  be  argued  that  any  such  algorithm  also  has  to 
tokenize  the  logical  units  mentioned  earlier,  and  that  this 
could  increase  the  degree  of  complexity  of  the  algorithm.  As 
long  as  there  is  a fixed  upper  bound  on  the  number  of  characters 
in  a token,  this  is  not  the  case.  This  is  because  tokenizing  a 
oarticular  string  of  characters  would  not  be  a function  of  n, 
but  of  the  fixed  bound. 

The  conclusions  of  the  above  discussion  can  be  embodied  in 
the  following  theorem, 

Ineorem  7.1,1:  The  complexity  of  an  algorithm  to  check  any 
design  in  the  DL  for  syntactical  correctness  need 
be  no  greater  than  0(n),  where  n is  the  number  of 
statements  in  the  design. 


7,2  The  Complexity  Of  Checking  DL  Designs  For  Absence  Of  Deadlock, 

To  develop  a measure  of  the  complexity  of  an  algorithm  that 
checks  designs  in  the  DL  for  absence  of  deadlock,  some  results 
about  networks  of  modules  must  first  be  established, 

A network  of  modules,  N,  can  be  viewed  as  a directed  graph 
G(N).  The  nodes  of  the  graph  are  the  various  modules  and  the 
arcs  are  the  interconnecting  links.  Let  DN  be  the  class  of 
networks  described  by  the  DL.  The  following  transformation  can 
then  be  described. 

Transformation  7,2.1:  Given  a network  N such  that 

A.  N e DN. 

B.  G(N)  is  circuit-free. 

Then  T is  a transformation  which  when  applied  to  N produces 
a new  network  T(N).  An  example  of  the  transformation  is  shown  in 
figure  7.3*  It  is  performed  at  a block  level  and  can  therefore 
be  thought  of  as  a transformation  on  the  inter-block  matrix.  The 
transformation  discards  those  SR  modules  associated  with  the 
auxiliary  inter-block  matrix,  and  replicates  those  blocks  that 
are  used  more  than  once,  thus  eliminating  all  the  SR  modules.  T 
is  deadlock  preserving:  if  network  N has  a potential  deadlock, 
then  so  will  T(N). 


It  is  now  possible  to  take  a network  N,  which  is  in  general 
composed  of  So,  Si,  W,  S,  -J , SR,  D and  I modules,  and  if  N e DN , 
convert  it  to  a new  network  T(N)  composed  of  So,  Si,  W,  S,  J,  D 
and  I modules  which  has  the  same  deadlock  characteristics.  For 
networks  without  SR  modules  a set  of  necessary  and  sufficient 
conditions  to  ensure  deadlock-free  operation  has  been  presented 
in  [Bru].  These  are  as  follows: 

If  N is  a network  without  SR  modules  it  is  deadlock- free  iff 

1.  The  I modules  are  two-way  articulation 
poin ts  in  G ( N ) . 

2.  The  D modules  are  three-way  articulation 
points  in  G(N). 

*Jhen  the  I,  D and  Si  modules  are  removed  the  remaining 
components  are  composed  of  So,  W,  S and  J modules. 

3.  These  components  must  be  circuit-free. 

4.  Their  precedence  grapns  (see  definition 
7.2.1  below)  must  be  circuit-free. 

Definition  7.2.1:  If  N is  a circuit-free  network  of  So,  W,  S and 

J modules,  the  precedence  graph,  P(N), 
associated  with  N is  formed  as  follows. 


Label  each  S module  in  N distinctly,  1 thru  s.  Associate  an 
s component  vector  P,  called  the  precedence  vector,  with  each 
output  link  of  N,  such  that: 


Where  p 


P = '‘P, Ps  > 

0 if  there  exists  a directed  path  in  G(N)  from  the 
primary  output  of  S module  i to  the  output  link. 

1 if  there  exists  a directed  path  in  GdO  from  the 
secondary  output  of  i to  the  output  link, 

X otherwise. 


tach  output  link  of  N,  and  hence  each  precedence  vector, 
corresponds  to  a node  in  P(N).  If  a and  b are  two  nodes  in  P(N) 
with  corresponding  precedence  vectors  P and  Q,  then  there  is  an 
arc  from  a to  b,  if  for 


P = <P,  , . . . ,Ps> 


= 1. 


there  exists  an  i such  that  p =0  and  q 


The  use  of  the  term  precedence  can  be  understood  if  the 
lollowinff  observation  is  noted.  An  arc  from  a node  ''a"  to  a node 
'■b'  , in  FfN),  implies  the  existence  of  an  S module  in  N,  which 
causes  the  rea uest /acknowledge  signal  cycle  on  the  link 
corresponding  to  ''a"  to  precede  that  on  "b''. 

The  following  theorem  can  now  be  enunciated, 

Iheorem  1,2.':  Given  a network  N such  that 

A,  N e DN, 

B,  G(N)  is  circuit-free. 

Then  N is  deadlock-free. 

Proof:  The  transformation  T may  be  applied  to  N,  since  N by 
hypothesis  satisfies  the  two  conditions  necessary  for  T 
to  be  applied. 

By  theorem  9.1  (see  section  9,  the  apoendix)  T(N) 
satisfies  the  conditions  1,2,3  and  4 above.  Hence  T(N)  is 
deadlock-free. 

Since  T(N)  is  deadlock-preserving,  oy  implication  N is 
deadlock-free. 

w ■ b . u. 


from  theorem  7.2.1  it  can  be  seen  that  in  order  to  check  a 
design  in  the  DL  for  absence  of  deadlock,  if  it  has  already 
passed  the  syntax  checker,  it  is  necessary  to  check  that  G(N)  is 
circuit-free.  This  check  can  be  done  directly  from  the  DL 
desciption  of  the  design. 

This  subsection  can  now  be  concluded  with  a final  theorem, 
which  gives  a bound  on  the  complexity  of  checking  designs  in  the 
DL  for  absence  of  deadlock. 

Iheorem  7.2.2:  The  complexity  of  an  algorithm  to  check  any 
design  in  the  DL  for  absence  of  deadlock  need  be 
no  greater  than 

0(  sf  + . . . + s?  + b^  ) 

where  b is  the  number  of  blocks  in  the  design, 
and  s,  thru  s^  are  the  numbers  of  statements  in 
the  respective  blocks. 
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Froof:  From  theorem  7.2.1  it  is  clear  that  the  check  consists 
0 f 

A.  Checking  to  see  if  N c DM. 

B.  Checking  to  see  if  G(N)  is 
circuit-f  ree. 

From  theorem  7.1.1  it  is  seen  that  task  A need  have  a 
complexity  no  greater  than  0(n),  where  n is  the  number  of 
statements  in  the  design. 

From  theorem  9.2  (see  section  9,  the  appendix)  it  is  seen 
tnat  task  B need  have  a complexity  no  greater  than  0(s^  + 

. . , + s|  + b2  ) . 

Since  n = s,  + . . . + , 

then  n < sf  + . . . + s? 

and  0(n  + + ...  + s^)  = 0(s^+  ...  + s^ ) 

Hence  the  complexity  of  an  algorithm  to  check  any  design 
in  the  DL  for  absence  of  deadlock  need  be  no  greater 
than 

0(  s^  + ...  + s-^  + b^ ) 

•.  L'  Pi  D 


7.3  The  Complexity  Of  Checking  An  Arbitrary  Network  of  Modules 

For  Absence  Of  Deadlock. 

No  necessary  and  sufficient  conditions  to  guarantee  absence 
of  potential  deadlock  exist  (as  of  January  19Vb)  for  arbitrary 
networks  of  So,  Si,  W,  S,  J,  SH,  D,  and  I modules.  Nevertheless , 
they  do  exist  (as  was  seen  previously)  for  subsets  of  these 
modules.  Theorem  7.3,1  , below,  shows  that  the  complexity  of  an 
algorithm  associated  with  checking  arbitrary  networks  of  the 
subset  of  modules.  So,  VI,  S,  and  J,  is  0(s,k2+  m)  , vnere  s is 
the  number  of  S modules,  k is  the  number  of  output  links,  and  m 
is  the  total  number  of  modules.  Hence  the  complexity  of  an 
algorithm  to  check  for  absence  of  deadlock  in  such  networks  is 
at  least  0(s,k^+  m)  and  hence  the  complexity  of  an  algorithm 
which  performs  the  check  for  the  complete  set  of  modules  is  at 
least  0(s,k^+  m) , because  it  must  include  networks  of  So,  W , S 
and  J modules  as  a special  case. 

Theorem  7. 3. 1 : The  complexity  of  an  algorithm  to  form  the 
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precedence  graph  for  any  network,  N,  composed 
only  of  So,  w,  S,  and  J modules  is  0(s,k^  + m) , 
where  s is  the  number  of  S modules,  k is  the 
number  of  output  links  and  m is  the  total  number 
of  modules. 

I'roof  : To  form  P(  N ) 

1,  Generate  (k)  s element  precedence  vectors.  These 
correspond  to  nodes  in  P(N). 

2.  Compare  pair-wise  the  precedence  vectors.  This  g: ves 
the  arcs  of  P ( N ) . 

Step  ' involves  visiting  each  arc  in  G(N)  once.  None  of 
the  modules  So,  W,  S and  J has  more  than  two  output 
links,  hence  the  number  of  arcs  in  G{N)  is  0(m).  Hence 
the  complexity  of  step  1 is  0(m). 

Step  2 involves  s.k.(k  - l)/2  comparisons.  Hence  the 
complexity  of  step  2 is  O(s.k^). 

Hence  the  combined  complexity  is  0(s.k^  + n). 

Q.  E.  D. 


7.M  Comparing  Computational  Complexities. 

In  subsection  7.2  a measure  of  the  complexity  of  checking 
the  design  of  a CS  for  absence  of  deadlock,  if  the  design  is 
described  in  the  DL , was  developed.  In  subsection  7.3  a similar 
measure  was  developed  if  the  design  was  the  result  of  an 
unstructured  interconnecting  of  modules  from  the  module  set. 
These  are  compared  in  figure  7.^.  The  values  substituted  for  the 
parameters  in  the  case  with  the  DL  are  shown  explicitly.  The 
values  used  in  the  case  without  the  DL  need  some  explanation. 

It  is  assumed  that  the  design  procedures  being  compared  are 
being  used  to  design  the  same  target  system.  Then 

no,  output  links  inj  = | no.  REG-TRF  statements 
the  case  without  J [in  the  DL  case, 
the  DL. 

If  it  is  also  assumed  that  the  number  of  REG-TRFs  is  a 
constant  fraction  of  n,  the  total  number  of  statements.  Then 

k = 0(n) 
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I 


With  DL:  0(s^  + ...  + ) 

' b 


Without  DL:  0(s.k^  + m) 

k = 0( n ) 
s = 0( n ) 

Ti  = 0(  n ) 


0(n2)  0(n2)  0(n''*) 


0(  ) 


0(n)*  0(n)*  0(n)* 


b = 1 corresponds  to  a design  in  the  DL,  described  in  one 
block. 

b = n corresponds  to  a design  in  the  DL , with  one  statement 
per  block  (the  comple.ment  of  the  b = ' case), 
b = yn  corresponds  to  a design  in  the  DL,  with  an  equal 
number  of  statements  per  block  (s,  = ...  = S|j  = yh ) . 


Figure  7.4.  A Comparison  Of  Complexities. 


Furthermore,  since  each  statement  corresponds  to  one  S 
module  (see  the  translation  procedure  in  section  U),  and  both 
procedures  aim  at  producing  behaviorally  equivalent  CSs,  it  is 
assumed  that 

s = 0( n ) 

Finally,  it  is  assumed  that  neither  approach  is 
significantly  more  economical,  in  terms  of  the  number  of  modules 
used.  Hence; 

m = 0(n) 

With  these  assumptions,  it  is  clear  from  figure  7.4  that 
fault  free  design  is  easier  from  a computational  complexity 
viewpoint  if  the  DL  approach  is  used.  If  the  block  structure 
facility  is  properly  used  (idealized  in  figure  7.4  as  yh  equal 
blocks  of  ypi  statements)  the  advantage  is  more  pronounced. 
Furthermore,  as  can  be  seen  from  the  assumptions  made  in  proving 
theorem  9.2  in  the  appendix,  the  complexity  of  an  algorithm  to 
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check  for  absence  of  circuits  in  the  network  of  modules 
associated  with  the  design  in  the  DL  is,  in  most  cases,  more 
likely  to  be  0(s,  + ...  + s^j  + b).  Such  cases  are  represented  in 
figure  7. '4  by  the  entries  with  asterisks.  These  indicate  a 
further  advantaRe  for  the  DL  approach. 

In  concluding  this  subsection,  a weak  point  in  the  preceding 
arguments  should  be  pointed  out.  The  complexity  of  the  algorithm 
to  form  the  precedence  graph  developed  in  theorem  7.3.1  is  not 
shown  to  be  a lower  bound,  as  it  ideally  snould  be  to  reinforce 
the  conclusions  arrived  at  when  comparing  the  complexities  of 
tne  two  design  procedures.  Nevertheless,  it  should  be  born  in 
mind  tnat  this  is  only  one  of  many  tasks  involved  in  the  lareer 
task  ot  checking  any  network  for  absence  of  deadlock,  as  was 
notea  in  section  7.3. 


7.5  Comments  On  The  Quantitative  Look  At  The  DL. 

If  reaucing  the  computational  complexity  of  the  design  task 
makes  it  easier  for  a human  to  perform  the  task  fault-free,  then 
it  can  be  seen  from  the  preceding  sections  that  the  second  of 
tne  two  aims  stated  in  the  introduction  (to  specify  a DL  so  that 
design  faults  can  be  easily  avoided)  has  been  achieved. 

Deciding  whether  reducing  the  computational  complexity  of  the 
aesign  task  makes  the  task  easier  for  a human  cannot  be  done 
quantitatively.  Nevertheless,  there  is  a consensus  that  would 
equate  reduced  complexity  with  ease  of  human  performance,  if 
account  is  taken  of  how  the  complexity  is  reduced.  In  section  6 
it  was  seen  that  the  reduction  of  complexity  is  accomplished  by 
using  a DL  whose  syntax  has  no  facility  for  unrestricted 
branching,  and  which  is  block  structured,  so  that  any  design 
must  be  formulated  in  a top  down  fashion.  This  maintains  a 
correspondence  between  the  textual  description  of  the  CS  of  the 
digital  system  and  its  proposed  operation.  Advocates  of 
structured  programming  consider  that  this  correspondence  greatly 
enhances  the  fault-free  properties  of  the  design  procedure 
viewed  as  a human  task  [Mil],  From  this  point  of  view  the  second 
aim  has  been  achieved. 


-52- 


b.  CONCLUSION 


Ihe  approach  to  designing  digital  systems  that  is  promoted 
in  this  report  can  be  summarized  as  follows.  Logic  gates  are 
organized  into  asynchronous  modules,  which  in  turn  are  organized 
into  constructs  in  the  DL.  At  each  stage  a certain  flexibility 
is  given  up  in  order  to  simplify  the  design  process.  Too  much 
flexibility  can  confuse  the  design  process,  too  little  can  limit 
the  class  of  systems  that  it  is  possible  to  design. 

{•  rom  a more  general  viewpoint  a hierachy  of  models  can  be 
seen  : 


1.  Quantum  mechanical  theory 

2.  Circuit  theory 

3.  Switching  theory 
i*.  The  DL 

Each  level  uses  some  of  the  products  of  the  previous  lower 
level  as  primitives.  Selecting  which  products  to  use  as 
primitives  needs  to  be  done  intelligently  and  with  a specific 
model  in  view.  (E.g.  op-amps  are  a product  of  level  2,  but  are 
useless  primitives  for  switching  theory. ) If  the  selection  is 
done  judiciously  it  can  result  in  a simple  model,  which  avoias 
pitfalls  possible  in  badly  specified  models.  Thus  the  underlying 
precept  is  prevention  rather  than  cure. 

In  conclusion  it  can  be  said  that  this  report  presents  a 
model  - a DL  for  digital  systems,  whose  primitives  - the 

asynchronous  modules,  are  products  of  switching  theory  (see  the 
list  above).  Furthermore,  and  this  is  the  novel  point  to  the 
report,  this  model  is  shown  by  quantitative  arguments  to  be  a 
better  model  for  design  than  the  ad  hoc  interconnection  of  the 
modules  to  suit  each  design  problem.  The  ad  hoc  interconnection 
of  modules  to  one  another  can  be  thought  of  as  a crude  DL  in 

which  the  step  from  level  3 to  level  h has  been  taken 

thoughtlessly.  (This  highlights  the  need  for  careful 
specification  when  proposing  a DL. ) 
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9.  APPENDIX 


Iheorern  9.1:  Given  a network,  N,  such  that 
A.  N € DN, 

E,  G(N)  is  circuit-free. 

Then  T(N)  satisfies  the  conditions  1,2,3  and  h of 
section  7.2  that  are  necessary  and  sufficient  for 
absence  of  deadlock. 

Proof  (part  I):  Assume  T(N)  violates  condition  for  a 

particular  I module.  Then  G(T(N))  must  be  of  the 
form  shown  in  figure  9.1. 

Since  T(N)  has  no  SR  modules,  node  "a"  must 
represent  a J module.  This  implies,  that  either 
there  exists  a block  in  T(N)  which  has  a J 
module  at  its  head,  or  else  there  exists  a block 
in  T(N)  containing  an  I module  which  does  not 
head  the  block. 

Transformation  T does  not  alter  the  intra-block 
connections.  But  J modules  cannot  occur  at  the 
head  of  blocks,  and  I modules  can  only  occur  at 
the  head  of  blocks,  therefore  (see  section  4.1) 
the  initial  assumption  must  be  false. 

Hence  T(N)  satisfies  condition  1. 

Proof  (part  2):  Similarly  it  can  be  shown  that,  as  long  as  N 
satisfies  the  hypotheses  A and  B,  T(N)  satisfies 
condition  2. 

Proof  (part  3):  Condition  3 is  satisfied  by  hypothesis  B. 

Proof  (part  4):  Removing  the  I,  D and  Si  modules  from  T(N) 
leaves  reworks  of  So,  W,  S and  J modules. 

Consider  one  of  these  networks.  Its  directed 
graph  representation  can  be  viewed  as  a tree 
whose  nodes  are  blocks  of  W,  S and  J modules. 
The  top  of  the  tree  may  be  capped  by  an  So 
module.  Figure  9.2  depicts  such  a tree.  The  arcs 
out  of  each  node  represent  outout  links  of  the 
network  (designated  leaves  in  the  figure)  or 
links  to  other  blocks  of  W,  S and  J modules. 
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As  was  seen  in  section  4. 1 , these  blocks  have 
only  a single  input  link  and  no  intra-block 
connections  involve  the  primary  output  links  of 
S modules.  This  implies  that  the  precedence  of 
the  arcs  out  of  a node  representing  such  a 
block,  form  a partial  ordering. 

Starting  at  the  root  of  the  tree  a partial 
ordering  can  be  formed  among  the  links  out  of 
the  root.  This  can  then  be  expanded  to 
incoperate  the  partial  ordering  among  the  links 
of  each  one  of  the  successor  nodes.  Continuing 
down  the  tree  in  this  fashion  yields  a partial 
ordering  representing  the  precedence 
relationship  between  the  output  links  or  leaves 
of  the  tree. 

Since  a partial  ordering  is  circuit-free, 
condition  4 is  satisfied  by  T(N). 


Theorem  9.2:  The  complexity  of  an  algorithm  to  check  whether  the 
modular  realization  of  a design  in  the  DL  is 
circuit-free  need  be  no  greater  than 

0(  s^  + ...  + + b^ ) 

where  b is  tne  number  of  blocks  in  the  design,  and 
s,  thru  s.  are  the  number  of  statements  in  the 
respective°blocks. 

Proof:  The  modular  realization  of  a design  is  circuit-free  if 
the  realization  of  each  block  is  circuit-free  and  if  the 
inter-block  connections  are  also  circuit-free. 

for  each  block  the  order  information  can  be  viewed  as  a 
directed  graph  represented  as  an  adjacency  structure 
(recall  the  interpretation  "successor  of"  used  in  section 
4).  The  modular  realization  of  each  block  is  circuit-free 
if  this  graph  is  circuit-free.  Johnson  [Joh]  presents  an 
algorithm  which  finds  all  the  elementary  circuits  of  such 
a graph.  The  complexity  of  the  algorithm  is  0((v  + e)(c  + 
1)),  where  v is  the  number  of  vertices,  e is  the  number 
of  edges  and  c is  the  number  of  circuits. 

For  a block  having  s statements  the  worst  case  is  given 
by 


V = s 

e = s^/4  (The  unlikely  case  ol 
the  order  information 
describing  a 

bipartite  graph. ) 
c = 0 (The  algorithm  is  being 
used  to  confirm  that 
the  design  is  circuit 
f ree , ) 

This  yields  a complexity  for  the  single  block  case  oi  no 
greater  than  O(s^). 

The  inter-block  connections  are  defined  by  the  way  blocks 
"call"  each  other  and  are  explicitly  denoted  by  the  block 
statements.  This  can  also  be  viewed  as  a directed  graph 
represented  as  an  adjacency  structure.  If  tne  design  has 
b blocks,  the  above  reasoning  yields  a complexity  for  the 
inter-block  case  of  no  greater  than  O(b^). 

Hence,  for  a design  having  b blocks  with  s,  thru  s^j 
statements,  the  complexity  of  an  algorithm  to  cnecK 
whether  the  modular  realization  is  circuit-free  need  be 
no  greater  than 

0(  sf  + ...  + s^  + b^ ) 

Q.b. D. 

Note  that  in  most  cases,  for  a block  having  s statements 
e is  more  likely  to  be  closer  to  0(s)  than  O(s^). 
Similarly  for  a iesign  having  b blocks,  e is  more  likely 
to  be  closer  to  0(b)  than  O(b^). 
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